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1.0 INTRODUCTION 


This report documents the work accomplished in the Diagnostic System 
Architecture Study (Task Order 4.0 of the Development of Life Prediction Capabilities for 
Liquid Propellant Rocket Engines program. Contract NAS3-25883). 

The objectives of this task were (1) analyze the current process used to make an 
assessment of engine and component health after each test or flight firing of an SSME, (2) 
develop an approach and a specific set of objectives and requirements for computer 
automated diagnostic processing during the post fire health assessment, and (3) list and 
provide high level descriptions of the software applications which need to be developed. 

The first two of these objectives were addressed in Task 1 of this study. Section 3 
of this report discusses the current system of diagnostics, specific user requirements and 
the overall approach recommended to automate these user needs. 

The final objective of the study was to describe the software required to develop 
this overall approach. This was accomplished in Task 2 and the results are discussed in 
Section 4 of this report. 

Finally, a brief outline for the development and implementation of this system was 
prepared. Section 5 of this report describes a recommendation for the phased development, 
testing, and implementation of the system. 
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2.0 SUMMARY 


The diagnostic system architecture study was a four month effort which 
accomplished three major objectives. The three objectives were to (1) analyze the current 
process used in making an assessment of engine and component health after each test or 
flight firing of an SSME, (2) identify specific system objectives and an approach to the 
development of automated diagnostic processing during post fire health assessment, and 
(3) list and provide high level descriptions of software applications needed to implement the 
approach. 

The first objective was met through interviews with people who were or are 
currently involved in post-fire health assessment of the SSME. Analysis of the current 
procedures used to make health assessments and specific system requirements were 
formulated. The source and attributes of the data used to make health assessments were 
traced and the procedures, (both manual and computerized) which are used to generate and 
present the diagnostic evaluations of engine and component health were observed and 
documented. Figure 2-1 describes the current overall process of post test health 
assessment of the SSME. Figure 2-2 shows the current computing environment used for 
post test diagnostics. 

The second objective was the development of an approach to enhance the diagnostic 
process by applying automated diagnostic tools. Figure 2-3 summarizes the distributed 
architecture of the recommended system. This architecture was designed to solve problems 
observed in the current diagnostic procedures and to address specific user requirements and 
desired functionality. The distributed architecture of the system allows the utilization of 
both the existing computer systems and the hardware upgrades (i.e., the Sun workstations 
and VAX 6320) planned under the Life Prediction contract and at MSFC. 

The third objective of this study was the identification, organization and description 
of the software required to implement this approach. Figure 2-4 summarizes the software 
modules and applications required for implementation of the system. The complete 
diagnostic system is organized into five major modules which provide management and 
integration of the various data sources, statistical analysis and graphical presentation of the 
hot fire data data, automated data evaluation, expen-system based health assessments and 
utilities for system administration and maintenance. 

Finally, a brief outline for the development and implementation of this system was 
prepared. Figure 2-5 shows a scheme for the phased implementation of these capabilities. 
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FIGURE 2-1 The Overall Process of Post Test Diagnostic Assessment 
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FIGURE 2-2 Current Computing Environment for Post Test Diagnostics 
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3.0 


TASK 1 - SELECT APPROACH 


3.1 INTRODUCTION 

This section of the report presents an analysis of the current approach to post fire 
diagnostics and health assessment. Specific areas of the current system which may be 
improved through the application of intelligent automated tools are identified and discussed. 
Finally, a conceptual design for an automated system to aid the diagnostic process is 
presented and specific uses and benefits of the system are detailed. 

A detailed understanding of the current diagnostic procedures and data flow came 
through discussion with people involved in post fire diagnostics of the SSME. This list of 
experts included personnel from NASA-MSFC, NASA-LeRC and NASA contractors from 
Martin Marietta, Aerojet, Boeing Computer Services, and Rocketdyne. Many of these 
people were interviewed in person during a trip to NASA-MSFC, which provided an 
opportunity to observe first hand the diagnostic process and current data handling 
procedures. 

From these interviews, specific user requirements emerged. Each person 
interviewed was given the opportunity to describe computer-based tools which they would 
find useful during post fire data evaluation. More often than not, they had some very firm 
ideas of what they wanted and needed. 

A conceptual approach was developed integrating these new capabilities with 
enhancements to the current system. This contrasts with providing a totally independent 
and isolated diagnostic system. The approach utilizes NASA's current and to-be-delivered 
computer hardware and software. While at NASA-MSFC the conceptual design of the 
system was discussed with potential users and administrators of the system. In these 
meetings, the approach was well received and users confirmed that the approach was 
responsive to their objectives and requirements. 


3.2 CURRENT DIAGNOSTIC PROCEDURES 

During our analysis of the current approach to post fire diagnostics, emphasis was 
placed on the evaluation of test (as opposed to flight) data because evaluation of test data is 
the larger job with more potential operations cost benefit. There are two reasons for this. 
First, more data is evaluated from the test stand than from the flight engines because there 
are many more engine tests than orbiter flights. Second, the instrumentation set is larger on 
the test stand than on the flight engines. This enables diagnostic evaluations and special 
studies based on test stand data which are not otherwise available from flight data. Still, 
there are many similarities in the procedures and techniques used to evaluate flight data, and 
it is safe to say that a diagnostic system which can effectively aid the evaluation of test 
stand data can also be applied to the analysis of flight engine data. 

The procedures used during post fire diagnostics have evolved with the SSME and 
have become efficient through repetition, discipline, and the dedication and enthusiasm of 
the individuals involved. During this evolution, a number of guidelines have remained 
constant which must be recognized in any attempts to improve the system. One of these 
guidelines is that no tests are conducted until the data from previous firings has been 
thoroughly reviewed and evaluated. This imparts a severe time constraint on the 
evaluators. Post test diagnostics and health assessments are often started and completed 
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within 24 hours of a test firing. Frequently, all instrumentation traces are reviewed and 
diagnostic conclusions formally presented within the same workday. 

A second guideline used is that independent, corroborative assessment of the data 
be performed. This extends throughout the organizations which evaluate the data. At the 
highest level, teams from Rocketdyne and MSFC make independent evaluations of the test 
data. Within each diagnostic team, independent analysis and evidence is presented by the 
test engineers on turbomachinery, dynamics, combustion devices, and systems groups. 
The principle of independent corroboration of the diagnostic conclusions is maintained in 
all cases. Figure 3-1 presents the structure of the organizations which support the post fire 
data evaluations. 

Figure 3-2 shows the overall post test diagnostic cycle for the SSME. Each circle is 
numbered indexing it to more detailed diagrams shown in subsequent figures. The focus 
of this program will be in defining and improving process 3.0 which is titled "Perform 
Diagnostic Assessment." This is the process where four major groups analyze the data 
determining if the test objectives were met and if there were any observations, anomalies, 
or failures which may impact the readiness of the engine for subsequent tests. However, to 
fully analyze the diagnostic process, and to enable improvements in the system, the other 
processes, particularly numbers 1.0 and 2.0 of Figure 3-2, were also examined in detail. 
In these processes, data is transferred from the test stand and compiled into the test data 
books. 


Figure 3-3 shows some details of the process used to transfer data from the test 
stand to the data processing center at Marshall Space Flight Center. Separate recording 
systems are used to capture the CADS, Facility, and Analog data. After the digital sets 
(CADS and Facility) are converted to engineering units, they are transferred via telemetry to 
a Perkin Elmer computer (PE4) at MSFC. In parallel, the analog data is digitized and 
telemetered to the same PE4 system at MSFC. Analog tapes are also available for 
processing on one of two Masscomp computer systems separately administered and 
maintained by the Dynamics group. 

The PE4 system is capable of storing up to 38-40 tests of CADS and Facility data 
and one ( 1 ) test of transformed analog data on line. Tape backups are archived for each set 
of test data. Administration and maintenance of the PE4 system is performed by 
contractors from NTI. 

Once the data has been received and backed up at MSFC, contractors from Boeing 
Computer Services make the test data books (process 2.0 of Figure 3-2). At the heart of 
this process is a FORTRAN program on the PE4 called Plot. This program is used to 
construct a standard set of graphs showing a sensor value versus time. The test data books 
are complete by the beginning of the day after a test. Special plots, such as expanded 
scales on one or more axes, or plots of one sensor against another are constructed upon 
special request to the Boeing support personnel, or by an interactive session with the Plot 
program. Presentation quality charts with annotation or regression fits of the data are 
constructed by downloading selected data via modem from the PE4 to a PC or Macintosh. 
DeltaGraph, a Macintosh statistics/graphics package, is used to construct these presentation 
quality charts. 
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FIGURE 3-1 Organization of Post Test Diagnostic Teams 
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FIGURE 3-2 The Overall Process of Post Test Diagnostic Assessment 
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FIGURE 3-3 Transfer of Data from Test Stand to MSFC 
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Experts from each of the four major disciplines shown in Figure 3- 1 evaluate the 
data contained in the test data book (process 3.0 of Figure 3-2). Possible sensor failures 
are identified by visual examination of the temporal plots and are then discussed and 
resolved with instrumentation specialists. Unexpected observations or anomalous engine 
behaviors are also identified through visual inspection of the temporal plots. Experts from 
each discipline consult with one another, or with test engineers at Stennis Space Center 
when an unusual data trace is observed. Results from manual post test inspection of the 
hardware are available, but not normally consulted unless an observation is made from the 
data traces or an unsatisfactory condition is observed during the inspection. Access to 
historical sensor data is generally limited to two previous cases which are presented with 
the standard data plots. Previously observed failure signatures are not generally available 
and are recognized only through the experience and expertise of the individual evaluators. 

Unusual occurrences or performance outside the relevant specifications are recorded 
via the UCR or RID systems. These test events are formally discussed internally at the 
post test data review and externally with Rocketdyne at the Pre-Test Readiness Review. 
Conclusions from evaluating of the test data are recorded in a test summary prepared by the 
Systems Group. 

The Systems Group at MSFC has taken responsibility for maintaining historical test 
records. They prepare the test summary for each hot fire test which is a compilation of 
selected plots from the test data book. In addition, they maintain databases on an IBM-PC 
which records hot-fire test descriptions, engine hardware configurations, test anomalies, 
descriptions indications, resolutions and results of inspection reports, and statistical 2- 
sigma bands around sensor values recorded at various steady state operating points. These 
applications are all independent of one another and the data is entered and updated 
manually. 

Figure 3-4 shows a schematic of the overall computing environment used for post 
test diagnostics by the engine Systems, Combustion Devices, and Turbomachinery groups 
at MSFC. Shown on this figure is the Perkin Elmer 4 system which is used to receive, 
store and archive the test data, the Tektronics terminals which supports past test analysis 
and the modem links to IBM-PC and/or Macintosh computers. 


3.3 USER OBJECTIVES AND REQUIREMENTS 

This section describes potential improvements to the current diagnostic process 
through the use of automated tools. It is not intended to criticize the diagnostic teams or 
process at MSFC. Indeed, the greatest asset of the current diagnostic system is the quality 
and dedication of the people who process and evaluate the test data. Rather, this section of 
the report will focus on areas of the diagnostic process for which significant benefit can be 
realized through automation. 

As discussed in the previous section, the current diagnostic process consists of five 
distinct steps. These steps are 1) Transfer Data, 2) Preparation of Data Books, 3) Conduct 
Diagnostic Evaluations, 4) Post Test Data Review, and 5) Test Readiness Review. 
Difficulties associated with each of these steps will be discussed. 
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FIGURE 3-4 Current Computing Environment for Post Test Diagnostics 






3.3.1 Transfer of Data 


The recording and communications systems which captures and transmits the test 
data appear to be effective and reliable. The PE4 system and support staff are well 
established and adequately handle data receipt, on line storage and data archival. 
Particularly important is the PE4's ability to receive and record real time VDT transmissions 
from flight missions of the Shuttle. 

The most significant limitation of the PE4 system is the limited storage of only a 
relatively small number of test cases. Only one (1) set of dynamics data are available on 
line. Additionally, up to 40 CADS and Facility sets (approximately 3 months worth of 
tests) are available at any given time. This storage issue is being addressed through the 
addition of optical disk drives. Although these drives are slow, they are capable of holding 
up to 60 additional tests of CADS and Facility data. The Dynamics data will soon be stored 
on two new Masscomp systems which will be supported by the Dynamics group. 

This study does not recommend any significant changes to the current system of 
data transmission, storage, and archival. The current procedures should be used by the 
new Diagnostic System. 

3.3.2 Preparation of Test Data Books 

Production of the test data books is one of the major deficiencies which can be 
addressed through the use of improved automation tools. A number of specific problems 
in the current process are discussed below. 

First, production of a test data book requires at least 4 to 5 hours. This is a major 
bottleneck in the diagnostic process which is currently addressed by assigning production 
personnel on off shifts to producing the book. One reason the production requires so much 
time is that each data book contains approximately 300 separate plots of sensor values 
versus time. We have not explicitly identified the need for each of these plots; however, 
we sense from our interviews that a more refined construct of the data presented may 
reduce the number of individual plots required. 

Second, the data books contain a very limited set of automated evaluations. No 
comparisons to standard acceptance specifications or even simple 2 sigma envelopes are 
presented. The individual evaluator is responsible for providing the other data necessary to 
identify relevant test events or anomalies. 

Third, the program which generates the test data books (the Plot program) is not 
very powerful or flexible. The Plot program produces the data books by executing a 
runstream file (a macro-like file of keystrokes) which generates the standard plots. Only a 
limited number of standard plot formats are available and construction of new formats or 
data manipulations requires modification of the Plot FORTRAN source code. For this 
reason, Systems Group personnel more typically download the data through a modem and 
perform custom manipulations and/or presentations of the data using desktop computers. 

Fourth, the Plot program allows no more than 1000 data points per curve At the 
maximum sampling rate of 50 Hz, this is only 20 seconds of data from one transducer. If a 
larger data set is requested, Plot automatically skips intermediate points, and effectively 
plots the data at a lower frequency to limit the number of data points plotted. This 
sometimes eliminates fast, but important test events from presentation on the plots. 
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A description of how these deficiencies will be resolved by the Diagnostic System 
is included in Section 3.4 of this report. 

3.3.3 Data Evaluation 

Evaluation of the test data is the next step in the overall diagnostic process. In 
general, the diagnostic evaluations rely heavily on the experience and ability of the 
individuals performing the assessments. Standardization and methodical evaluation of 
engine performance historical trends or inviolate specifications are not emphasized. As a 
result, a reasonably high level of on-the-job training and experience is required for the 
production of accurate and consistent diagnostic evaluations. A number of specific 
examples from our observations at MSFC made this point clear. 

First, very little automated evaluation of the data is currently performed. Direct, 
single sensor 2 sigma, green run, or acceptance specification violations are not 
automatically diagnosed and highlighted. Instead, manual evaluation of the test data reveals 
these direct violations. 

Second, there is no formal catalog of historical observations of the engines and their 
data signatures. The Systems Group has recently started to maintain a local database of 
observed test anomalies and a verbal description of the supporting evidence. However, 
this database is not used to support the current diagnostic process because it contains a 
small number of failures with no unexplained observations from previous tests. Presently, 
when an anomaly or observation is identified in the current test data, reference to previous 
test(s) which were diagnosed with the same anomaly is accomplished through the 
individual's recollection. "I remember something like this happened about nine months 
ago," was a comment that started a search back through the test summary books for related 
historical evidence and failure signatures while we were at MSFC. 

Third, there is little automated reference to the operating history of individual 
engines or components. Data from two selected tests are shown on most of the standard 
plots contained in the data book. Frequent changes in test objectives and engine 
configurations often make direct comparison of current test data with previous firings 
difficult. Still, important historical trends in the operation of engine components is 
frequently not included in the standard data package. Drawing upon a case observed at 
MSFC, test data was compiled which showed that over the three previous firings of an 
engine, there was an increasing trend in the cavity pressure outside the main chamber liner 
cooling channels (see Figure 3-5). This is a strong indication of a leak between the cooling 
channels and the liner closeout The plot was compiled only after manual evaluation of the 
data trace from the third firing and it revealed an unusually high pressure in the cavity. 

The operating history of individual engines or components would be useful to 
assess the operational life and firing history of engine components. The number of starts 
and seconds on bearing sets was of importance in trending turbopump bearing wear data. 
Currently this is tracked informally by the Dynamics group. Another example was a 
comment regarding data presented for a low pressure fuel pump, "Yes - but doesn't this 
pump always run a little cool?" This started a long, unresolved discussion about the 
historical operation of the component. It was obvious that there was no single, direct way 
to answer this question. In fact current procedures would require queries of configuration 
data from TRACER to determine which tests used the turbopump in question. This would 
then be followed by manual review of the data from these tests. 
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3.3.4 Post Test Data Review 


The problems observed during the post test data review were primarily a result of 
the deficiencies discussed in preparation and evaluation of the test data. Questions about 
the history of the engine components came up frequently and the discussions often ended 
without clear answers to the original query. Automated access to a historical test 
information database would significantly reduce these problems. 

3.3.5 Pre Test Data Review 

The problems observed during this pan of the diagnostic process are primarily the 
result of deficiencies in previous steps. The major difficulty with this portion of the 
process is the difficulty personnel at MSFC have corroborating information presented by 
Rocketdyne. This was particularly evident in the discussion of DAR reports. DAR reports 
show the component history in terms of starts and seconds of hot fire life experienced on 
critical components for the upcoming test. 


3.4 PROPOSED APPROACH 

The proposed diagnostic system architecture has been designed with consideration 
to planned MSFC data processing capabilities. The software will combine existing (but 
currently separate) capabilities with new data analysis and expert aided diagnostics 
producing a fully integrated system hosted from an engineering workstation. We have 
evaluated the user benefits associated with the proposed implementation verifying the 
payoffs from each system component. We have developed an implementation plan for 
providing the workstation package to MSFC in an incremental fashion to quickly realize a 
portion of the benefits and provide an experience base which will help in completing the 
balance of the complex, expert system implementation. 

3.4.1 System Configuration 

The proposed workstation architecture will build upon the upgrades to the existing 
data processing network at MSFC (see Figure 3-6). MSFC is installing a VAX 6200 
system linked to the Perkin-Elmer processor (PE4) over a high speed data link. Current 
MSFC plans call for the new VAX system to support multiple users at terminals throughout 
the propulsion laboratories. The VAX users will be able to generate requests to the PE-4 
ADP staff moving test data from tape to disk or to automatically move test da ta from optical 
media to high speed disk. Data will be extracted from the PE-4 databases and moved to 
local VAX storage to assist in engineering analyses performed locally. 

The proposed software architecture will use a portion of the VAX disk storage 
system for a local, integrated database of SSME test data and along with other historical 
and configuration information. These integrated databases will be accessed by a network 
of data analysis workstations which will be interconnected on the existing LAN and use the 
VAX as a file server. To workstation users, the system will appear as a distributed 
database managed by the INGRES database manager. Access times for the workstation 
users should be excellent based on the high performance of the VAX disk drives and 
DECNET LAN. Thus, the actual data residency will be invisible to the workstation users. 
The local workstation disks will be sufficient for temporary and user generated data storage 
along with storage of local software applications as required. 
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FIGURE 3-6 The Proposed Diagnostic System Will Be Built On Planned MSFC 
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The workstation hardware will be based on a RISC implementation. The 
workstation will have integer performance in excess of 12 million instructions per second 
(MIPS) and floating point performance in excess of one million double precision operations 
per second (UNPACK). It will provide a minimum of 8 MBytes of RAM and a 64 KByte 
cache to increase throughput. The workstation connection to the DECNET/Ethemet LAN 
will operate at 10 Mbits/second. The local mass storage will be in excess of 100 MBytes of 
SCSI hard disk storage with 22 milliseconds average seek time and 1.2 MBytes/second 
transfer rate. There will be a large, color graphics monitor with optical mouse. The 
operating system will be a UNIX-based multi-tasking window system with pull-down 
menus enhancing the user interface and reduce training requirements. 

Implementation of the full expert-aided diagnostic system will require four to eight 
workstations networked into the VAX file server. The current architecture being 
implemented by MSFC will permit this without difficulty. 

3.4.2 Proposed Software Functionality 

3 . 4 . 2 . 1 Integrated Database Environment 

3.4.2. 1.1 Maintain SS ME Test Database 

These applications will transfer SSME test data from the PE4 computer into the file 
server database. The application will allow sufficient flexibility to transfer all or part of the 
test time and all or part of the engine’s sensor set at various sampling rates. 

Requests to the PE4 operators to move the test database from tape or from optical 
storage will be created as required. The data will be transferred over the high speed data 
link using the file transfer protocol best suited for the data, e.g., TCP/IP. File 
compression/decompression will be performed if beneficial to the overall efficiency of the 
process. 

Data will be loaded into the integrated database on the file server and indices created 
for access. These applications will allow the user to manage test data stored on the file 
server including record display, deletion, editing, etc. 

3.4.2. 1 .2 Maintain Anomaly and Incident Reports 

Applications will be provided to store anomaly data derived from previous test 
reviews into an integrated database. This information will include narratives describing 
anomaly characteristics, causes determined, and identifying sensors. In addition, data 
traces showing the anomaly signature may be incorporated into the data record. The 
anomaly will be represented with a group of sample data traces from involved sensors or, 
more generally, using feature descriptors such as slope, level and duration of the response. 

Records can be entered, deleted, edited and/or displayed. Data indices will include 
test number, date and affected engine components. 

3.4.2. 1.3 Maintain Two-Sigma Database 

Applications will allow storage and retrieval of two-sigma data bands for start-up, 
mainstage and shutdown. The two-sigma bands will be available for plotting and 
comparison with actual test data. The bands will be updated with selected test runs on user 
request. New bands may be created for new or varied test scenarios. Applications will be 
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provided to examine ensembles of test runs and extract the two-sigma data bands so that 
customized bands can be created for specific SSME configurations. 

3 . 4 . 2 . 1 . 4 Maintain Configuration Data 

Applications will enable tracking of the major SSME components' operating 
history. Since parts tracking is performed by the TRACER program, this application will 
principally download configuration data to the file server and provide a subset of the 
TRACER records for correlation during test data analysis. 

In addition, an on-line query generator will be provided to automatically generate a 
TRACER data extraction for specific configuration requests. For example, if the 
installation history of a particular HPOP was required, the user would complete the several 
entries on a workstation form. The application would connect to the TRACER mainframe 
at Canoga Park, run the required job stream, recover the data and incorporate it into the 
database for inspection and correlation with test data. 

3. 4. 2. 1.5 Maintain Specification Data 

Data on specification requirements will be maintained to aid in the automated 
evaluation of acceptance test and green run data. Data will reflect the minimum and 
maximum acceptable sensor values for all engine measurements called out in the applicable 
specifications. Storage of these values in the integrated database will permit automatic 
updates to the evaluation criteria if engine requirements or design changes affect the 
specifications. 

Records can be entered, deleted, edited, and/or displayed. The specification data 
will be indexed on specification type, operating phase and sensor identifier. 

3 . 4 . 2 . 1 . 6 Maintain Inspection Data 

Data from each manual inspection of the engine are now maintained by the Systems 
Group. The data provides added evidence to evaluate hypotheses about observed test 
events. Inspection reports from previous firings of specific engine components are also 
used during post-test data reviews. Storage of these inspection reports in the integrated 
database will be helpful in supporting expert-aided automated diagnostics. 

Records can be entered, deleted, edited, and/or displayed. The inspection data may 
be manually or automatically queried for specific test numbers, dates, LRU numbers, or by 
the identification of certain test events in the data. 

3. 4. 2. 2 Computer Aided Engineering (CAE) Environment 

3. 4. 2. 2.1 Plotting Applications 

A comprehensive color data graphing application will allow test engineers to plot 
test information in a variety of formats. Test to test comparison, multi-variable plots, two- 
sigma overplots and other analysis requirements will be supported by the application in 
conjunction with the databases. 

These applications will allow specific plots to be stored in the database. There will 
be an extensive range of standard chart formats including multi-plot, multi-line, bar, pie, 3- 
D, etc. Plot parameters or templates can be stored so that standard plot reports can’ be 
designed and created automatically when test data becomes available. 
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The plot applications will be based on third party graphics and data analysis 
packages suitable for the workstation. Over forty such packages were reviewed in Task 2 
of this study. Section 4.3 of this report discusses this review and recommends seven 
candidates for further evaluation. 

Minimal computer programming is required and the interface will use multiple 
windows with a mouse. Zooming will dynamically rescale local areas of the plot for closer 
examination under mouse control. 

3. 4. 2. 2. 2 Data Processing/Statistic Applications 

A general purpose computer-aided engineering (CAE) function will allow direct 
manipulation of data vectors by the user through non-programmatic mathematical 
expressions. The CAE function will support all types of signal processing and analysis 
techniques including digital filters, FFT, statistical filters (e.g., maximum likelihood, 
Kalman, etc.), dynamic modelling, regressions, ARMA, etc. Free form analyses by the 
user will be provided using direct mathematical expressions or predefined functions that 
operate on the data. Results will be expressed in a tabular or graphical output, or 
maintained as intermediate values in a multi-step analysis. These free form analyses will 
provide an additional basis for knowledge capture in the expert application. 

3 . 4 . 2 . 2 . 3 Report Generation Application 

An application will provide standard report formats which integrate graphical data 
presentations with text from related databases or manual input. These reports can be 
automatically produced when a specific set of flight data are studied for test evaluation and 
health assessment. The reports will be user generated and easily modified to support 
unique investigations. 

3.4.2. 3 Special Applications 

3. 4. 2. 3.1 Sensor Validation 

An application (developed under a separate task) will provide sensor validation. 
Test data sequences will provide the input to the program determining indications of faulty 
sensors. Sensor faults such as bias shift, scale factor error, noise, and environment-caused 
errors will be addressed by the package. In addition to the error indications, an estimate of 
the corrected sensor readings will be produced. 

3. 4. 2. 3. 2 Start/Main Stage/Shutdown Analysis 

The performance of the engine against the applicable ICD, Green Run, or 
Acceptance Specifications will be evaluated automatically. Exceptions to performance will 
be generated and form the basis for diagnostic analysis by the users and the expert aided 
system. 

3 . 4 . 2 . 3 . 3 General (2- S igma/Features) Exception Analysis 

An application will automatically screen data sequences against two-sigma bands 
established for the specific test scenario. Exceptions will be generated to initiate diagnostic 
analysis and provide supporting information to the expert aided data analysis applications. 
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An application will automatically screen test phase data against feature descriptors 
for normal and anomalous behavior. SSME faults exist which do not cause exceedances of 
2-sigma bands, but which exhibit either unusual or identified abnormal behavior. An 
example of this is fuel side oscillations which occasionally occur during shutdown. 
Exceptions to either two-sigma or normal feature definitions will be logged and recorded 
against the test sequences in question. Troubleshooting applications will use these 
indicators and the established diagnostic rule base to correlate identified exceptions with 
known failure modes. 

3. 4. 2. 3. 4 Power Balance Model 

The power balance model will be integrated into the test analysis environment. 
Averaged test data will be created for inputs and outputs relating to Kf s, etc., and will be 
incorporated into the test phase reports. The model will also be used for 2-sigma steady- 
state detection during specific test phases. Additional applications and special 
investigations will also be supported within the workstation environment. 

3. 4. 2. 4 Expert Aided Diagnostics 

3. 4. 2. 4. 1 Maintain Diagnostic Rules (Anomaly Associations) 

Diagnostic rules will assist the analyst in correlating observed indicators (data 
exceptions) with one or more previously identified anomalies. The anomaly database will 
be built from test experience and history. The inference process which links specific data 
exceptions with the abnormalities will be captured in the rule base. This function will 
capture the knowledge linking the exceptions with faults. The representation selected will 
recognize the attributes of the abnormality and search for matching indications in data. 
After analysis of the exception, the knowledge base will be updated automatically (under 
manual control) to capture the reasoning and outcome of the analysis so that it can be 
applied to future occurrences. 

3. 4. 2. 4. 2 Perform Aided Diagnoses 

This application will lead the user through a structured analysis of one or more 
abnormal indications. The inference structure represented in the knowledge base will be 
used as the basis for the analysis; however, at any time, the user can examine specific data 
on the current test and from prior occurrences of suspected anomalies. 

The user's path through the inference process will be automatically captured by the 
system using the transaction log. This log will form the basis for rule-base updates using 
the expert system's knowledge maintenance tools. The application will allow partial 
diagnostics of multiple exceptions so that the user can combine conclusions between 
exceptions. The linking of multiple diagnostic goals is an inherent feature of the 
NEXPERT Object shell selected for the application. 

3. 4. 2. 4. 3 Advanced Diagnostic Applications 

Advanced applications will be integrated into the workstation data environment to 
support special investigations and advanced diagnostic development. The intent of the 
computing environment is to provide the flexibility to incorporate advancing capabilities 
rapidly and cheaply in an incremental manner. Advanced features may include deep- 
reasoning diagnostic systems which incorporate physical models of SSME faults and 
automatic knowledge generation/maintenance tools applicable to the problem. 
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3.4.3 A pplication Users and Benefits 


We have partitioned the system into applications which support the various data 
users. For each application, there are one or more benefits that the new workstation 
implementation will provide. In Figure 3-7, we have compiled a list of the benefits of each 
application area and associated them with the user groups deriving the benefit. It is clear 
from the figure that there are several applications which will immediately benefit several 
user groups and that benefits will be provided at each level of system implementation. 
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FIGURE 3-7 Post-Fire Health Assessment Workstation User Benefits 
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FIGURE 3-7 Post-Fire Health Assessment Workstation User Benefits (Cont’d) 
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FIGURE 3-7 Post-Fire Health Assessment Workstation User Benefits (Cont’d) 
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FIGURE 3-7 Post-Fire Health Assessment Workstation User Benefits (Cont’d) 
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4.0 


TASK 2 - SYSTEM DEFINITION 


4.1 HIGH LEVEL ORGANIZATION 

This section describes the software required for an automated system to perform 
post fire diagnosis and health assessment of the SSME. The system is designed to meet the 
user requirements and provide the benefits discussed in section 3.0 using a distributed 
architecture approach. 

Figure 4-1 maps the logical organization of the system. The system requires 
database management, CAE capabilities for data manipulation, presentation and plotting, 
special applications for specific data evaluations, and expert systems (under the Nexpert 
Object Expert System Shell). Procedural portions of the code will be written in C. 



Anomalies 
2 -Sigma Data 
Configurations 
Ins pad ions 
Test Dei a 
Specifications 


Planing 

Statistical Analysis 
Report Generation 
Signal Processing 


Sensor Validation 
Startup Analysis 
Main Stage Analysts 
Shutdown Analysis 
2 Sigma Exceptions 
Green Run Analysis 
Power Balance Model 
Transient Analysis 


Feature Identification 

Feat ures_to_ Anomalies 

Expen 'Aided 
Diagnostics 

Advanced Diagnostics 


Security 

Install 

Oocumem 


FIGURE 4-1 Overall Organization of Diagnostic System 

The executive program provides the primary user interface for these system and will 
reside on a Sun workstation. The workstation will in turn generate requests for data and/or 
calculations on one or more of the other systems (VAX, PE-4, and IBM) as required using 
the existing LAN at MSFC. These requests and the background processing will be made 
transparent to the user. 


Data used by the system to make diagnostic evaluations will be stored on the VAX 
6320 at MSFC under the Ingres relational database management system. Specific database 
structures and attributes are described in section 4.2 of this report. 

Presentation and analysis of data will be accomplished with the aid of a commercial 
analysis, graphics and statistics package. Over forty commercial packages were examined 
during the course of this study and a list of eight packages has been recommended for 
further evaluation. Section 4.3 of this report discusses both the use of CAE packages 
within this diagnostic system and examines the capabilities of the packages. 

Diagnostic evaluation and analysis of hot fire data is conducted in two areas of the 
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system. The first of these is called the special application module. The second is called the 
expert-aided diagnostic module. Classification of the diagnostic applications into one of 
these two areas is preliminary. For example, there is some merit in classifying the program 
which analyzes hot fire data against the green run requirements as an expert system 
diagnostic. However, we have chosen to classify it as a special application because the 
green run evaluation criteria is relatively straight-forward and does not require heuristic 
reasoning or interpretation based on experience. 

The special applications module, then, is a collection of diagnostic routines that are 
primarily procedural in nature. These evaluations are currently performed in a relatively 
structured and repeatable manner during the course of the data analysis. Some of these 
special applications exist as stand-alone applications on MSFC processors (the PE-4, IBM 
mainframe or EBM-PC) and are currently supporting the diagnostic activity. Development 
efforts will be concentrated on making these individual programs work together within the 
integrated diagnostic system. Each special application is discussed in more detail in Section 
4.4. 


The expert-aided diagnostics module will use expert systems technology based on 
the NEXPERT Object shell to emulate the heuristic evaluations and health assessments 
currently performed by experienced engineers. A knowledge base will be constructed to 
automatically identify features (with a confidence factor) in the hot fire data. These features 
and confidence factors along with other information concerning the test, engine 
configuration, inspection reports, etc. will then be used to diagnose the cause of the 
anomalous behavior. Section 4.5 presents the applications and knowledge bases required 
for development of these capabilities. 


4.2 INTEGRATED DATABASE 
4.2.1 Application List and Outputs 

The integrated database provides the foundation for the diagnostic system. The 
database consolidates information from sources which are currently disconnected. The 
purpose of the integrated database is to provide a consistent format and a universally 
available platform to all of the data which is relevant to the diagnostic process. 

Six general categories of data were identified as important and useful in the 
diagnostic process. These categories are: 

a. Engine Build Configurations & Operating Profiles (i.e., component 
history); 

b . Identified Operating Anomalies; 

c. Hardware Inspection Reports; 

d. Statistical (2-Sigma) Norms; 

e. Specification Requirements; and 

f . Test or Flight Measurements (i.e., CADS, Facility, and Analog 
data). 

This data originates from a variety of locales. The current data storage formats 
include from an IBM DB2 database, IBM-PC Symphony file to hand-written reports. The 
source of each of these data types are listed in Figure 4-2. 
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FIGURE 4-2 The Integrated Database Consolidates Diagnostic 
Information from Various Sources 
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FIGURE 4-3 Summary of Database Applications 
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The integrated database will be hosted on a VAX 6320 at MSFC under the Ingres 
database management system (dBMS). Maintenance of the data in the integrated database 
will be accomplished by a combination of Ingres capabilities and procedural programs. 
Manual updates to the contents of the data Files will be possible through Ingres. Automated 
updates of the configuration, anomaly, sigma and test data files will be accomplished via 
procedural programs working in conjunction with Ingres. 

Standard reports on the contents of individual data files in the integrated database 
will be provided under Ingres. On-line repons which involve joins of data from various 
data categories and files will be provided through Ingres in response to user-defined 
queries. 

Figure 4-3 shows the applications which will be provided to maintain and report the 
contents of the integrated database. 

The physical output of the integrated database will be reports which show the 
current contents of the database files. These are the standard reports listed in Figure 4-2. 
An example of a standard report is shown in Figure 4-4. 


DATABASE REPORT FOR FILE: Sigma'Values 



DATE:31 Aug 1990 
Operating Power 

PID 

Sensor 

Mean 

One Sigma 

Phase 

Level 

Number 

Description 

Value 

Value 

Mainstage 

100 

163 

MCC Pc 

3006.25 

1 .31 

Maintstage 

100 

203 

LPFP DS P 

224.80 

12.92 

Mainstage 

100 

225 

LPFP DS T 

42.62 

0.48 

Mainstage 

100 

152 

HPFP DS P 

5878.55 

36.03 

Mainstage 

100 

231 

HPFTT A 

1662.71 

59.41 

Mainstage 

100 

232 

HPFTTB 

1678.84 

45.95 

Mainstage 

100 

261 

HPFTPSPD 

34389.38 

238.97 

Mainstage 

100 

209 

LPOP DS P 

352.40 

19.10 

Mainstage 

100 

190 

HPOP DS P 

3883.72 

23.92 

• 

• 

• 

• 

• 


• 

• 

• 

• 

• 


• 

• 

• 

• 

• 



FIGURE 4-4 Typical Report of Database Contents 


4.2.2 Data Structures 


Preliminary Ingres file structures were developed for each of the major data 
categories. These file structures are shown in Table 4-1, and include the field name, data 
type and field length. Four data types were used: character, integer, floating point, and 
note. The length of character, integer, and floating point fields are shown in Table 4-1. 
The note data type is a field of dynamically variable length which can hold text or graphical 
information. 
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DATABASE: CONFIG 


File: Hardware 

TESTNO. I, 6 
TESTDATE, C, 6 
ENGINE, C, 6 
HPOP'UN, C. 8 
HPFP'UN, C, 8 
LPOP'UN, C, 8 
LPFP'UN, C, 8 
HPOP’SN, C, 8 
HPFP'SN, C, 8 
LPOP'SN, C, 8 
LPFP'SN, C, 8 
PWR'HEAD, C, 6 
MAIN’INJ, C, 6 
MCC, C,6 
NOZZLE, C, 6 
CNTRLR, C, 6 
HPOP’IMP, C, 10 


File: Test’Profile 

TESTNO, I, 6 
STARTTIME, F, 6 
END’TIME, F, 6 
POWER'LEVEL, F, 6 


DATABASE: ANOMALY 

File: Anomaly'List 

TESTNO, I, 6 
ANOMALYTIME, F, 6 
ANOMALY-COMP-NAME, C, 6 
RID’NO, I, 6 
MR'NO, I, 6 
UCR'NO, I, 6 

ANOMALY'DESCRIP, NOTE 
ANOMALY-SIGNATURE, NOTE 
ANOMALY-RESPONSE. NOTE 


TABLE 4-1 File Structures 
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DATABASE: INSPECTIONS 


File: HpopTRpt 

ENGINE, 1, 4 

TEST’NO.1,6 

INSP'DATE,I,6 

ENGINEER, C,35 'inspection engineer 

TT' B R K , F , 6 'breakaway to rque 

TTPRM,F,6 'running torque 

TTCOM.NOTE torque comments 

SM'OVERALL.NOTE lurbine inlet sheetmetal appearance 

SM'STRUT'LEAD.NOTE 

SM'STR UPSIDE, NOTE 

SM'STRUTTRAIL.NOTE 

SM'STRUT'WELDS.NOTE 

Sl'NOZ'OVER ALL, NOTE 

SI 'NOZ'IO'SHROUD.NOTE 

SI 'NOZ'VANE'LEAD.NOTE 

SI 'NOZ'VAN E'AI R .NOTE 

SI 'NOZ’VANE'TR AIL, NOTE 

SI 'TURB'BLD'LEAD.NOTE 

Sl'TURB'BLD'AIR.NOTE 

SI TURB'BLDTSHROUD.NOTE 

SI 'TURB'BLD'O'SHROUD.NOTE 

BRG'3’C AGE, NOTE 

BRG'3'R ACE, NOTE 

BRG'3'B ALLS, NOTE 

BRG'3'PHOTOS,C,1 

MAIN'IMP.NOTE 

TURN' VANE, NOTE 

PBP'INLET.NOTE 

PBP'IMP'BOLT'LOCK.NOTE 

PRI'LOX'SL'LEAK'CHK'DATE,C,6 

PRI'LOX'SL'LEAK'RATE.F,6 

PRI'TURB'SL'LEAK'CHK'DATE.C.e 

PRI'TURB'SL'LEAK'RATE.F,6 

TEST'PLATE'THICKNESS,F,6 

BASE'MEASURE, F, 6 

MEAS'ROTOR'END'PI ,F,6 

MEAS'ROTOR'END'P2,F,6 

MEAS'ROTOR'END'P3,F,6 

MEAS'ROTOR'END'P4,F,6 

S2’TURB‘BLD,NOTE 

G2'SL,NOTE 

G3'SL,NOTE 

ER.NOTE ' eccentric rings 

TABLE 4-1 File Structures (Cont'd) 
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File: LpopTRpt 


ENGINE, 1, 4 

TEST’NO.1,6 

INSP'DATE,I,6 

ENGINEER, C, 35 'inspection engineer 

TT'BRK,F,6 

TTPRM,F,6 

TT'COM.NOTE 


File: HpfpTRpt 

ENGINE, 1, 4 

TEST'NO.1,6 

INSP'DATE.1,6 

ENGINEER, C, 35 'inspection engineer 

TT'BRK,F,6 'breakaway torque 

TTPRM,F,6 'running torque 

TT’COM.NOTE 'torque comments 

SHAFT-DIM, F, 6 

SHAFT'TVL,F,6 

B'M ARK' ALIGN, NOTE 

SM'OVERALL.NOTE turbine inlet sheetmetal appearance 

SM'STRUT'LEAD.NOTE 

SM'STRUTSIDE.NOTE 

SM'STRUTTRAIL.NOTE 

SM'STRUT'WELDS.NOTE 

KAISER'NUT.NOTE 

THERM'SHLD.NOTE 

Sl'NOZ'OVER ALL, NOTE 

SI 'NOZ'IO'SHROUD.NOTE 

SI 'NOZ'VANE’LEAD.NOTE 

SI 'NOZ'VAN E'AI R .NOTE 

SI 'NOZ'VANE'TR AIL, NOTE 

TURB'TIP’SL’OVER ALL, NOTE 

TURB’TIP’SL’FILLER.NOTE 

TURB’TIP'SL’JNT.NOTE 

Sl’TURB'BLD'LEAD.NOTE 

Sl'TURB'BLD’AIR.NOTE 

SI 'TURB'BLD'PLAT.NOTE 

Si 'TURB'BLD'TRAlL.NOTE 

SITURB'BLD'DAMP.NOTE 

PLATFORM'SL.NOTE 

TURB'DSCH'SM'OVERALL.NOTE 

TURB'DSCH'TA'MANI.NOTE 

TURB'DSCH'O’BELLOWS.NOTE 

S2'TURB’BLDTURB’DSCH,NOTE 

S2'TURB'BLD'DAMP,NOTE 

BAL‘PIST'GAP,F,6 

SHIMTHICKNESS.F.6 

BRG'INLET’COOL'HOLES.NOTE 

BRG'DSCH'COOL'HOLES.NOTE 

PUMP'END'TURB'END’SL.NOTE 

G6'FLANGE,NOTE 

SI TIP'SL'RETAIN'LUG.NOTE 

S2TIP'SL,NOTE 

TABLE 4-1 File Structures (Cont’d) 
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File: LpfpTRpt 


ENGINE, 1,4 

TEST'NO.1,6 

INSP'DATE,I,6 

ENGINEER, C, 35 'inspection engineer 

TT'BRK,F,6 'breakaway torque 

TTPRM,F,6 'running torque 

TT'COM.NOTE lorque comments 


File: CdevTRpt 

ENGINE, 1, 4 

TEST'NO,l,6 

INSP'DATE,I,6 

ENGINEER, C, 35 'inspection engineer 

SPARK'I .NOTE 

SPARK'2,NOTE 

ASI'OX'ORI.NOTE 

ASI'FU'ORI'NOTE 

ASI'CHAMBER.NOTE 

INJ'REM ARKS, NOTE 

MCC’ROUGH'BEFORE'TYP,C,15 

MCC'ROUGH'BEFORE'MAX,C,15 

MCC'ROUGH'BEFORE'3UP,C,15 

MCC'ROUGH'BEFORE'4DN,C,15 

MCC'REM ARKS, NOTE 

NOZ'REM ARKS, NOTE 

TPS’REM ARKS, NOTE 

FPB'BAFFLE'1 .NOTE 

FPB,BAFFLE'2,NOTE 

FPB,BAFFLE'3,NOTE 

FPB'SPARK'1 .NOTE 

FPB'SPARK’2,NOTE 

FPB'OX'ORI.NOTE 

FPB'FU'ORI.NOTE 

FPB'CC.NOTE 

FPB'REM ARKS, NOTE 

OPB'BAFFLE'1 .NOTE 

OPB,BAFFLE'2,NOTE 

OPB,BAFFLE'3,NOTE 

OPB’SPARK’1 .NOTE 

OPB’SPARK'2,NOTE 

OPB'OX'ORI.NOTE 

OPB'FU'ORI.NOTE 

OPB'CC.NOTE 

OPB’R EM ARKS, NOTE 

TABLE 4-1 File Structures (Cont'd) 
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DATABASE: SIGMAS 


Datafile: Sigma'Tests 

TESTNO, I, 6 
ENGINE’PHASE.C.I 
POWER'LEVEL, F, 6 
PID'NO,l,6 

MEAN'TEST’VALUE,F,6 


Datafile: Sigma’Values 

ENGINE'PHASE. C, 1 
POWER'LEVEL, F, 6 
PID'NO, I, 6 
MEAN'VALUE, F, 6 
ONE'SIGMA'VALUE, F, 6 


DATABASE: SPECIFICATIONS 
Datafile: Specifications 


SPEC’TYPE.C.I 'A (Acceptance), I (ICD), G (Green Run) 

PID’NO, 1, 6 

ENGINE’PHASE.C.I 'P( Pre-start), S(Start), M(Mainstage), D(Shutdown) 

STARTTIME, F, 6 

END'TIME,F,6 

HIGH'LIMIT,F,6 

LOW’LIMIT,F,6 

TREND'LIMIT,F,6 'In engineering units/sec 

VIOLATION-DESCRIPTION, NOTE 


TABLE 4-1 File Structures (Cont'd) 
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4.2.3 Database HTPO Analysis 


As discussed in Section 4.2.1, applications are required to maintain and report on 
the contents of the integrated database. A summary of the required applications was shown 
in Figure 4-3. This section defines each of these applications through the use of a 
Hierarchical Input Process Output (HIPO) analysis. Shown in these HIPO analyses are the 
input into each application, a description of the processing done within the application, and 
the output of each application. 


4.2.3. 1 Configuration Data 

4.2.3. 1 . 1 Automated Updates of Configuration Data 

4. 2. 3. 1.1.1 Input 

Configuration and test’profile datafiles. 


A. 

B. 

C. 

D. 


User request to automatically update the Configuration database for 
specified test number(s). 

Tracer hardware configuration files. 

SSME Test Data for selected test number(s). 


4.2.3. 1.1.2 Process 


A. Open communication link to RKDN Tracer Program. 

B. Retrieve test number, date, and LRU identifiers matching user request. 
Format data. 

C . Transfer update file to VAX. 

D. For each record in update file, 

Search for match in configuration file. (Key: test’no). 

If match 

THEN Replace existing record. 

ELSE Append new record 

E. Open communication link to PE-4. 

F . Locate SSME test data for the specified test(s). 

G . For each measurement point in test data file(s) 

( 1 ) Calculate power level, rounded to nearest percent 

(2) Test against previous power level calculation 

If equal 

THEN do nothing 
ELSE 

i. add end time to open test'profile record 

ii. construct new record with start time for 
test'profile 
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H . Load resulting file into Test'Profile datafile. 

(1) Append new records (key: test'no) 

(2) Replace existing records for key match 

4.2.3. 1.1.3 Output 

Automatically updated Configuration and test'profile datafiles for specified test 
number(s). 


4.2.3. 

4.2.3. 


4.2.3. 


1.2 Manual Updates of Configuration Data 

1.2.1 Input 

A. Configuration and test'profile data files. 

B . User request to manually update data 

1.2.2 Process 


A. User enters edit mode. 


B . Records appear from configuration and test'profile data files indexed by 
test'no. User has keyboard control to 

Add - new records 
Delete - a character, or record 
Change — contents of any field 
Save — work to date 
Abort — edits this session 

C. Upon exit of edit mode, edited records are saved. 

D. Reindex edited data files. 


4. 2. 3. 1.2. 3 Output 


4.2.3. 

4.2.3. 


4.2.3. 


Manually edited configuration and test'profile datafiles. 

1.3 Standard Reports of Configuration 

1.3.1 Input 

A. Configuration and test'profile data files. 

B. User request for standard report. 

C. User designation of report sort order and search condition(s). 

1.3.2 Process 

A. Open configuration and test'profile data files. 

B . Construct report based on specified sort order and search condition. 

C . Display results on screen or send to printer as requested 
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4. 2.3. 1.3. 3 Output 

Screen display or printed report shown in Figure 4-4. 

4. 2. 3. 2 Anomalies Data 

4 . 2 . 3 . 2 . 1 Automated Updates of Anomalies Data 

4. 2. 3. 2. 1.1 Input 

A. Anomaly datafile. 

B . Identified test anomaly from Expert- Aided Diagnostics Applications. 

C . User permission to record identified anomaly. 

4. 2. 3. 2. 1.2 Process 

A. Open Anomaly Datafile. 

B . Add new record with test'no, anomaly'time, anomaly’comp'name, anomaly 

description (text), and anomaly'signature (text and/or graphic(s)) as 
provided by expert aided diagnostic application. 

C . Note no search to prevent duplicate entries for same anomaly. 

D. Permit user to edit new data provided by expert aided diagnostic application. 

E. Permit user to add rid'no, mr'no, and ucr'no. 

4. 2. 3.2.1. 3 Output 

Anomaly datafile with added anomaly record. Possibly a new anomaly signature. 

4. 2. 3. 2. 2 Manual Updates of Anomalies Data 

4. 2. 3. 2. 2.1 Input 

A. Anomaly data file. 

B. User request to manually update data 

4. 2. 3. 2. 2. 2 Process 

A. User enters edit mode. 

B. Records appear from Anomaly data files indexed by test'no. User has 
keyboard control to 

Add — new records 
Delete — a character, or record 
Change — contents of any field 
Save — work to date 
Abort — edits this session 
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C . Upon exit of edit mode, edited records are saved. 

D. Reindex edited data files. 

4. 2. 3. 2. 2. 3 Output 

Manually edited Anomaly datafiles. 

4. 2. 3. 2. 3 Standard Reports of Anomalies Data 

4. 2. 3. 2. 3.1 Input 

A . Anomaly data file. 

B . User request for standard report. 

C . User designation of report sort order and search condition(s). 

4. 2. 3. 2. 3.2 Process 

A. Open Anomaly data file. 

B . Construct report based on specified sort order and search condition. 

C. Display results on screen or send to printer as requested. 

4. 2. 3. 2. 3. 3 Output 

Screen display or printed report. 

4. 2. 3. 3 Inspections/Data 

4. 2. 3. 3. 1 Manual Updates of Inspection Data 

4. 2. 3. 3. 1.1 Input 

A. Inspection data files. 

B. User request to manually update data 

4. 2. 3. 3. 1.2 Process 

A. User enters edit mode. 

B. Records appear from Inspection data files indexed by test'no. User has 
keyboard control to 

Add — new records 
Delete — a character, or record 
Change — contents of any field 
Save — work to date 
Abort — edits this session 

C. Upon exit of edit mode, edited records are saved. 
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D. Reindex edited data files. 

4. 2. 3. 3. 1.3 Output 

Manually edited Inspection datafiles. 

4.2.3. 3.2 Standard Reports of Inspection Data 

4.2. 3. 3. 2.1 Input 

A. Inspection data files. 

B. User request for standard report. 

C. User designation of report sort order and search condition(s). 

4.2.3. 3.2.2 Process 

A. Open Inspection data files. 

B . Construct report based on specified sort order and search condition. 

C. Display results on screen or send to printer as requested. 

4. 2. 3. 3. 2. 3 Output 

Screen display or printed report 
4. 2. 3. 4 Sigma Data 

4 . 2 . 3 . 4 . 1 Automated U pdates of Sigma Data 

4. 2. 3. 4. 1.1 Input 

A. Sigma data files. 

B . Temporary update file of validated SSME hot fire data as analyzed by 
special application module sigma. 

C. User permission to update sigma datafiles with data from this test. 

4. 2. 3. 4. 1.2 Process 

A. Open sigma data files and temporary update file produced by special 
application sigma. 

B . For each record in temporary update file. 

C. Search for match in sigma'test file (key: test’no + engine'phase + 
power'level + pid’no) 

If match 

THEN display record exists message. Allow user to overwrite. 
ELSE update sigma data files with info from new test. 
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4. 2. 3. 4. 1.3 Output 

Automated update of sigma data files. 

4. 2. 3. 4. 2 Manual Updates of Sigma Data 

4. 2. 3. 4. 2.1 Input 

A. Sigma data files. 

B. User request to manually update data. 

4. 2. 3. 4. 2. 2 Process 

A. User enters edit mode. 

B . Records appear from Sigma data files indexed by test’no. User has 
keyboard control to 

Add — new records 
Delete - a character, or record 
Change — contents of any field 
Save — work to date 
Abort - edits this session 

C. Upon exit of edit mode, edited records are saved. 

D. Reindex edited data files. 

4. 2. 3. 4. 2. 3 Output 

Manually edited Sigma datafiles. 

4. 2. 3. 4. 3 Standard Reports of Sigma Data 

4. 2. 3. 4. 3.1 Input 

A. Sigma data files. 

B . User request for standard report. 

C . User designation of report son order and search condition(s). 

4. 2. 3. 4. 3. 2 Process 

A. Open Sigma data files. 

B . Construct repon based on specified sort order and search condition. 

C . Display results on screen or send to printer as requested 

4. 2. 3. 4. 3. 3 Output 

Screen display or printed report. 
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4. 2. 3. 5 Specifications Data 

4. 2. 3. 5. 1 Manual Updates of Specifications Data 

4.2.3.5.1.1 Input 

A. Specification data files. 

B. User request to manually update data 

4. 2. 3. 5. 1.2 Process 

A. User enters edit mode. 

B . Records appear from Specification data files indexed by test'no. User has 

keyboard control to 

Add — new records 
Delete -- a character, or record 
Change — contents of any field 
Save — work to date 
Abort - edits this -session 

C. Upon exit of edit mode, edited records are saved. 

D. Reindex edited data files. 

4. 2. 3. 5. 1.3 Output 

Manually edited Specification datafiles. 

4. 2. 3. 5. 2 Standard Reports of Specifications Data 

4. 2.3. 5. 2.1 Input 

A. Specification data files. 

B . User request for standard report. 

C. User designation of report son order and search condition(s). 

4. 2. 3. 5. 2. 2 Process 

A. Open Specification data files. 

B . Construct report based on specified sort order and search condition. 

C. Display results on screen or send to printer as requested. 

4. 2. 3. 5. 2. 3 Output 

Screen display or printed report. 
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4. 2. 3. 6 Test Data 



4. 2. 3. 6.1 Automated Updates of Test Data 

4. 2. 3. 6. 1.1 Input 

A. Full SSME CADS or Facility Test data on Perkin Elmer-4. 

B . Test number, start and end times, and sampling rate provided by user. 

4. 2. 3. 6. 1.2 Process 

A. Open communications link to VAX. 

B . Lookup test number on VAX to see if a copy of data already exists for the 
requested test. 

C. If file exists on VAX 

THEN display existing header record information to user. 

Ask user if they want new data. 

EF user wants new data, 

THEN proceed to next step. 

ELSE end automated update without new data transfer 

D. Open communications link to PE-4. 

E. Lookup test number on PE-4 on-line disk storage. 

F. IF File exists on PE-4 

THEN proceed with data transfer per user request 

ELSE display not on line message to user. Allow tape load request 

4. 2. 3. 6. 1.3 Output 


SSME Data transferred from PE-4 to VAX at user requested sampling rate and start 
and stop times. Data storage format will be SSME Data Format D (see Table 4-2). 


Rec# 


Sec# 

Record Description 

0 

File Formatting Information 

1 

Comment Record 1 

2 

Comment Record 2 

3 

Comment Record 3 

4 

Comment Record 4 

5 

Comment Record 5 

6 

File Map (Time words) 

1 1 

File Map (Disk Records) 

16 

Zero Shift Data Averages 

• 

Stateness Factors 

* 

Header #1 (Test Title) 

* 

Header #2 (Test File Information) 


Header #3 (Measurement IDs) 

* 

Header #4 (Engineering units) 

* 

Header #5 (Measurement Titles) 


SSME Data Format 


Data Type/Size 


CMAR*252 

CHAR*252 

CHAR*252 

CHAR-252 

CHAR*252 

CHAR*252 

REAL 

INTEGER 

REAL 

REAL 

CHAR*? 

REAL 

CHAR*? 

CHAR*? 

CHAR*? 


D 


TW (315) 
DR (315) 
ZS (?) 

SF (?) 

HI 

H2 (63) 
H3 (?) 
H4(?) 
H5(?) 
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Rec# 


Sec# 


Record 


Description 


Data 


Type/Size 


16 


\ Up to 15 Optional User Detined 

\ Header Records 

> 

/ (number of records specified 

/ in header record 2) 


Data may be of 
any type and 
size. 


Start of Test Data 

\ 


Test Data Records 


EOF 


/ 

End of Test Data 


REAL 


* Sector addresses for these records are supplied by Header record number 2. 


TD (?) 


GENERAL RECORD DESCRIPTIONS FOR FORMAT D 

1) Record #1 contains information about the format of the file. The record is in FORTRAN type 
CHARACTER*252. For the “D" format the first 17 characters of this record are as follows: 

"DATA FORMATED XXX" 

2) XXX is a three digit integer number which holds the file sector number of header record 2 
This allows programs to quickly bypass comment and filemap records if so desired. Character 
positions 18 through 252 may be used as desired. Normally, the name of the file generating 
program and it’s version number are specified enclosed in asterisks (*). For example, if a program 
called “SCALETTB" were to produce a format “D” file, the first record might read: 

-DATA FORMAT-D 116 ‘SCALETTB vl.31*" 

3) The program name including the asterisks should not be over 20 characters long because 
utility routines exist which make this field available to user programs as a CHARACTER*20 entity. 
The program name field may appear anywhere in the record except in the first 17 characters. 

4) Records #2 through #6 is free file space not currently used. Any file creation program may 
use this area to hold comments, program specific data, ect. Each record is of type 
CHARACTER*252. 

5) Records #7 and #8 contain a map of the file's data area. Record #7 is 315 REAL words and 
record #8 is 315 INTEGER words. The file generating program does not compute the data for 
these two records; instead, programs write two dummy records as place holders. After the 
complete file is written, a program utility “FILMAP" is used to scan the test data portion of the file 
and overwrite the two dummy records with file mapping information. The methods used to map a 
file are detailed in document “SSME SINGLE ENGINE TEST DATA ACCESS" number IL 86-129- 
289 in section 3.7 “DAT ACC. LIB File Mapping Method". Programs which later read data may use 
routines designed to use the file map to directly access any record in the file's test data area. 

6) Record #9 contains zero shift averages as REAL words. The zero shift averages are 

produced by averaging the test data over the -2 to -1 second time period before engine start. The 
resulting averages may then be used by user programs to compute a bias to apply to certain test 
parameters in order to correct calibration. File generating programs do not not need to compute 
the data for this record; instead, programs write one dummy record of zero values (0.0) as a place 
holder. After the complete file is written, a program utility “FILEMAP" is used to compute the zero 
shift values and overwrites this record. If the zero shift values can not be computed, the zero 
values are left in place causing programs which use zero shifts to apply no bias. 

TABLE 4-2 SSME Data Format D (Cont'd) 
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7) Record #10 contains staleness factors for each measurement listed in record #13. The 
staleness factor is the time adjustment to be added to time to compute the exact time at which 
each individual measurement value was recorded. Any file creation program should compute 
these factors and insert this record. If the staleness factors are not known or not computable, a 
record of zero values (0.0) should be written. This will cause user programs which apply staleness 
to ignore any time adjustment. 

8) Record #1 1 contains the first of five standard header records. Header #1 constitutes the test 
title in FORTRAN type CHARACTER and may be of any length. Word number 22 in header #2 
points to the sector of header #1 and word 23 indicates it's length. A common CADS file might 
have “SSME CONTROLLER DATA FOR TEST 9010460" written in this record. 

9) Record #12 contains header #2. In this record there are 63 floating point words which give 
information about the test file itself. These 63 words are described by the following: 

WORD DESCRIPTION 

1 
2 

3 

4 

5 

6 

7 

8 

9 

10 
1 1 
12 

13 

14 

15-20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 


62 Sector Address of 15th User Header Record 

63 Entity Length of 15th User Header Record 

TABLE 4-2 SSME Data Format D (Cont'd) 


Spare (normally 0.0) 

Spare (normally 0.0) 

Number of PIDS contained in this file 
Spare (normally 0.0) 

Spare (normally 0.0) 

Number of PIDS plus one plus time word 
Spare (normally 1.0) 

'Test Stand Number (901 =A1, 902=A 2, 750=A3, 904=BI) 

'Test Run Number 

Year and Day (ie. 5070. for 85:070) 

Spare (normally 0.0) 

Spare (normally 0.0) 

Engine Cutoff Time in Seconds 

Sector Address of the Start of Test Data Area 

Calender Time of Engine Start in the form Years, Days, Hours, Mins, Secs, Msecs 

Engine Serial Number 

Sector Address of Header #1 

Character Length of Header #1 

Sector Address of Header #2 

Sector Address of Header #3 

Character Length of Header #3 

Sector Address of Header #4 

Character Length of Header #4 

Sector Address of Header #5 

Character Length of Header #5 

Sector Address of Zero Shift Averages 

Sector Address of Staleness Factors 

Number of User Defined Header Records (0-15) 

Sector Address of 1 st User Header Record 
Entity Length of 1st User Header Record 
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When this file format is used to contain STS flight data, a “single-engine-like" test run number 
must be synthesized for words 8 and 9. The method used is as follows: 

Word 8, Characters 1-3 - STS Mission Number or MPTATest Number 
Word 9, Character 1 = Cycle Number for MPTA or STS Scrub/Abort 
Word 9, Character 2 ■ Event Site (0-KSC, 1-VAB, 2-NSTL) 

W° rd 9, Character 3 = Event Type (0-STS, 1 -Scrub, 2-Abort, 3-FRF, 4-MPTA) 

Word 9, Character 4 = Engine Position (1-ME1 , 2-ME2, 3-ME3) 


c Re i??r!? #1 ? con,a,ns header #3 - This record is a list of the measurement IDs available in the 
'*• Each ID is of type CHARACTER and may ol any length. Header #2 words 25 Ind 26 s-Sv 
the sector address and string length ol header #3 entities. The order in which the measurements 

are bated identities the order in which all other header and data records are wrS The pTd 
number is usually in the first four characters. wrmen. i ne PID 

Record #14 contains header #4. This record supplies the engineering unit of measure for 

?? '"a ?f der #3 . Each unit is 01 •*» CHARACTER and may be ol any tenah ™ ad? #2 
and 28, specify the sector address and string length of header #4 entities. 

Each t ihe^ s * 0 ! type °C H FT4CT F nrf m f upplies the ti,,e of each rtem in header #3 
cdun uue is oi rype UHAHACTER and may be of any enath Headpr#? worric oq a n n in 

the sector address and string length of header #5 entitle? ' words 29 and 30 ’ s P ec,f y 

tlnl ’2 ; acord f, ma y be used by users to add special header records to the file The 

ype and length of the entities are up to the user to define. Since these records are oDtionai nn 

of %co?ds%ffn C e°d ^ <0r S ° m6 fHeS W ° rd 33 ° f header #2 s P ecifies »he number 



TABLE 4-2 SSME Data Format D (Cont'd) 

4. 2. 3. 6. 2 Manual Updates of Test Data 
4. 2. 3. 6. 2.1 Input 

Test Data data files. 

User request to manually update data 


A. 

B. 


4. 2. 3. 6. 2. 2 Process 


A. 


User enters edit mode. 


B. 


C. 


Records appear from Test Data data files indexed by test no 
keyboard control to 

Add — new records 
Delete - a character, or record 
Change - contents of any field 
Save — work to date 
Abort ~ edits this session 


User has 


Upon exit of edit mode, edited records are saved. 
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D. 


Reindex edited data files. 


4. 2. 3. 6. 2. 3 Output 

Manually edited Test Data datafiles. 

4. 2. 3. 6. 3 Standard Reports of Test Data 

4.2.3. 6.3.1 Input 

A. Test Data data files. 

B . User request for standard report. 

C . User designation of report sort order and search condition(s). 

4. 2. 3. 6. 3. 2 Process 

A . Open Test Data data files. 

B . Construct report based on specified sort order and search condition. 

C. Display results on screen or send to printer as requested. 

4. 2. 3. 6. 3. 3 Output 

Screen display or printed report. 


4.3 COMPUTER AIDED ENGINEERING 
4.3.1 Applications Programs 

Two applications are required to provide the necessary computer aided engineering 
(CAE) capability to the workstation (see Figure 4-5). An interface application will retrieve 
and format data from the integrated databases and a commercial CAE package will provide 
the graphical data analysis functions for the CAE environment. 

The data interface application provides access to SSME test and flight data as a user 
defined set of parameter retrievals from the Ingres database. The interface application will 
format the data for the analysis program as required. 

A commercial CAE application will be selected to provide the CAE environment. 
Data will be supplied to the program from the integrated database by the data interface 
application. Batch programs will generate pre-defined plots for each test segment. Output 
will be available on screen in real time, or as post-script output suitable for a laser printer. 
The user will be able to actively manipulate, analyze, and redisplay the test data sets using 
features of the commercial package. 

The analysis process for each SSME test or flight will begin when the parametric 
data has been transferred to the file server. Plot data set definitions and report formats 
developed by individual analysts will be input to this process. 
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PE4 Integrated Database 



FIGURE 4-5 CAE Functionality Will Be Provided by a Commercial CAE 
Program in Concert with an Automated Interface to the 
Integrated Database 
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The CAE application will be menu driven. The analyst can select pre-defined plot 
packages for on line examination or hard copy print. Data will include test parameters, pre- 
defined text, a textual data, curve fits, statistics, etc. defined for the plot format. The 
analyst can flexibly manipulate the plot display using the mouse to zoom and enhance 
scaling accuracy, identify numeric values of specific plotted points under mouse control, 
and edit data including cut/paste functions. Multiple windows can be opened 
simultaneously to compare data on different plots. 

Plot information may be printed at any time to the laser printers. Additionally, a full 
set of "canned" plots can be created in hard copy using a batch operation. 

Output formats will include a wide variety of 2D/3D formats for data display. Plot 
definitions will allow layouts to be pre-defined with plots produced when the program is 
executed. Plots which have been created can be stored and accessed for later comparison 
as examples of nominal or anomalous behavior. 

4.3.2 Evaluation of CAE packages 

Over forty commercial data analysis, graphics, and statistics packages were 
evaluated (see Figure 4-6) to determine their potential suitability for this application. The 
following required feature provided the basis for evaluation: 

a. Compatible with a SUN workstation including multi-window 
operation; 

b. Flexible data input formats including, if possible, easily 
implemented bridges to the Ingres databases and sufficiently large 
data table size; 

c. Flexible 2D/3D full color graphics including a wide variety of plot 
formats; 

d . Post-script output device support; 

e. Batch and macro operation available to provide standard sets of plot 
reports for each test segment; 

f. Application language for implementation of mathematical 
manipulation, statistics, and signal processing functions; 

g. Fully integrated mouse support including autozoom, data cut, paste 
and editing and data value examination under mouse control; 

h. Data management capabilities within the analysis program itself to 
allow storage and retrieval of plot images without regeneration of the 
parametric data; and 

i. Efficient operation and suitable response time on selected processor 
platform. 
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FIGURE 4-6 Summary of Commercial Packages Investigated (Cont'd) 
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FIGURE 4-6 Summary of Commercial Packages Investigated (Cont'd) 
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FIGURE 4-6 Summary of Commercial Packages Investigated (Cont’d) 




COMMENTS 

Full feature data analysis and plot 
package. 

Optimization Program. 

Interactive computing and 
visualization environment including 
image processing and animation. 
Allows access to C and FORTRAN 
routines from applications. Runs 
under X-Windows. 

2 

§• 

1 

No response. 

No response. 

Sophisticated mathematical 
processing environment with graphics 
capability. Environment centered 
around numerical analysis language 
with many, analysis functions. 

CAE environment with plotting 
capability 

No response. 

APPROX 

PRICE 

$ 2790 

$ 21000 

$4000 




$ 2500/yr 

$ 10000 


INPUT 

FILE 

FORMAT 

Many 

Several 

Program 




Many 

Many 


APPLI 

CATION 

LANGUAGE 

YES 

NO 

YES 




YES 

YES 


DATA 

MANAGE 

-MENT 

NO 

NO 

YES 




NO 

NO 


TYPE 

PLOT MATH STAT OTHER 
















X 

X 


X 

X 

X 




X 

X 


X 


X 




X 

X 


VENDOR 

SAS 

Institute 

Scicon Ltd. 

Scientific 

Computing 

Assoc. 

Scientific 

Computing 

Group 

Small 

Systems 

Sorites 
Group, Inc. 

Speakeasy 

Systems 

Control 

Technology 

Tektronix 

PROGRAM 

NAME 

Base SAS 
SAS/GRAPH 

MGG 

Sciconic 

CLAm 

DVERK 

Fractals Artist 
Toolkit 

SOR1TEC 

Speakeasy 

Grapheasy 

Ciil-C 

MathScribe 

CAN 

* 
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FIGURE 4-6 Summary of Commercial Packages Investigated (Cont'd) 







Several commercial CAE packages appear to satisfy these requirements. These 
packages (and vendors) are as follows: 

a. TECPLOT (Amtec, Inc.); 

b. RS/1 (BBN Software. Inc.); 

c. MATLAB (Mathworks, Inc.); 

d. TempleGraph (Mihalisin Assoc.); 

e. TECHBASE (MINEsoft Ltd.); 

f . PV~Wave (Precision Visuals, Inc.); 

g. S AS/Graph (SAS Institute, Inc.); and 

h. Unigraph 2000 (Uniras Inc.). 

More detailed evaluation and benchmarking of these candidates are recommended. 


4.4 SPECIAL APPLICATIONS 
4.4.1 Application List and Output 

The special applications module consists of diagnostic and data evaluation 
applications that are primarily procedural in nature. These applications are used to filter test 
data and identify directly measured operating anomalies and definitive violations of 
operating specifications. As such, they provide a first cut at the feature identification 
abilities required in the more sophisticated, heuristic data evaluations to be accomplished in 
the expert-aided diagnostics module. 

Many of these special applications are a part of the current diagnostic procedures. 
Some of these applications, such as for evaluation of green run data, have even been 
developed into FORTRAN programs on the Perkin Elmer and are currently in use as 
individual tools to aid in the diagnostic process. These programs will be ported to the Sun 
workstation and will be integrated into this diagnostic system. Thus, the current diagnostic 
procedures will be incrementally enhanced by building upon systems and procedures 
already in place. 

The special applications which have been identified as are: 

a. Sensor Data Validation and Signal Reconstruction; 

b. Startup Analysis; 

c. Shutdown Analysis; 

d. Main Stage Analysis; 

e. Green Run Analysis; and 

f . Steady State Power Balance. 

The user will start each of these applications through a menu-driven selection 
program on the Sun workstation. Each of these applications will operate on data stored in 
the integrated database. ' ' 

4 - 4 - 2 Special Ap plications HTPO Analysis 

Details of the input data requirements, the process logic and output from each of the 
special applications will now be presented in the form of HIPO charts. 
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This application will detect and isolate hard and soft sensor failures in the hot fire 
data, calibration and scaling errors will also be detected on certain critical parameters. When 
one of these sensor failure is identified, an estimate of the correct sensor value will be 
generated and the hot fire data set will be updated. 


4.4.2. 1.1 

A. 

B. 

C. 

D. 

4.4.2. 1.2 


Input 

User request to validate data. 

User supplied test number to validate. 

User supplied previous tests for comparison. 
CADS data for the selected tests. 

Process 


The process of the sensor validation task is currently being developed under the 
Sensor Data Validation Task of the Life Prediction Program. 

4. 4. 2. 1.3 Output 

A. Validated and Reconstructed PID’s. 

B . Identification of reconstructed PID numbers. 


4. 4. 2. 2 Startup Analysis 


This application will calculate critical characteristics of the startup transient (from 
engine start to engine start plus 6 sec) of the engine. Comparison of the engine start will be 
made against the start confirm criteria and the two sigma startup database. 

4. 4. 2. 2.1 Input 

A. User request to perform analysis of startup transient. 

B . User specified test number. 

C . CADS and Facility data for the test. 

D. Start confirmation criteria. 

E. Two sigma startup data. 

4. 4. 2. 2. 2 Process 


A. Open CADS and Facility data files for selected test. 

B . Open two sigma startup data file. 

C . Calculate prime times for 

( 1 ) Fuel pre-burner, 

(2) ox pre-burner, and 


62 



(3) Main combustion chamber. 


D. Evaluate turbine discharge temperature measurements against start conf irm 
criteria. 

E . Examine data for existence of fuel side oscillations. 

F. Compare sensor data with two sigma startup values. Report the number of 
two sigma excursions, the length of time above or below two sigma, and 
the minimum and maximum excursion from two sigma for each data 
channel evaluated. 

G . Generate temporary file of average values from this test for automated 
update of sigma values. 

H . Generate startup evaluation sheet 

4. 4. 2. 2. 3 Output 


A. Startup evaluation sheet. 

4.4.2. 3 Shutdown Analysis 

, u P 115 a PP llcation vvi11 calculate the shutdown characteristics of the engine. Evaluation 
of the thrust decay rate, purge and valve sequencing will be made against specification 
requirements. There is currently no two sigma database for shutdown values and 
development of one was not characterized as a high priority by the diagnostic expens. 

4. 4. 2. 3.1 Input 

A. User request to perform analysis of shutdown transient. 

B . User specified test number. 

C . CADS and Facility data for the test. 

D. Shutdown specification criteria. 

4. 4. 2. 3. 2 Process 

A. Open CADS and Facility data files for selected test. 

B . Calculate thrust decay rate. Compare with specification requirement. 

C. Calculate timing of the valve and purge shutdown sequence. Compare with 

specification requirements. F 

4. 4. 2. 3. 3 Output 

A. Shutdown analysis sheet. 

4. 4. 2. 4 Mainstage Analysis 

This application will compare steady state operation of the engine at all standard 
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power levels with the two sigma data bases. Performance comparisons will be generated 
for all measurements at standard power levels. 

4. 4. 2. 4.1 Input 

A. User request to perform mainstage two sigma analysis. 

B . User specified test number. 

C . CADS and Facility data for the test. 

D. Sigma database. 

4. 4. 2. 4. 2 Process 

A. Open CADS and Facility files and sigma database file 

B . Locate the point in the test of: 

( 1 ) Maximum fuel turbine discharge temperature at 65% RPL; 

(2) Maximum fuel turbine discharge temperature at 100% RPL; 

(3) Maximum fuel turbine discharge temperature at 104% RPL; 
and 

(4) Maximum fuel turbine discharge temperature at 109% RPL. 

C . For each of these test times, calculate: 

(1) HPOTP Inlet Pressure, psia; 

(2) HPOTP Discharge Pressure, psia; 

(3) PBP Discharge Pressure, psia; 

(4) LPTOP Speed, rpm; 

(5) HPOT Discharge Temp (Ch A), R; 

(6) HPOT Discharge Temp (Ch B), R; 

(7) HPOP Speed, RPM; 

(8) HPFTP Inlet Pressure, psia; 

(9) HPFTP Discharge Pressure, psia; 

( 1 0) HPFP Discharge Temp, R; 

(11) LPFTP Speed, RPM; 

(12) HPFTP Speed, RPM; 

(13) HPFT Discharge Temp (Ch A), R; 

(14) HPFT Discharge Temp (Ch B), R; 

(15) OPOV Position; 

(16) OPB Pc, psia; 

(17) FPOV Position; 

( 1 8) MCC coolant Discharge Temp, R; and 

(19) MCC coolant Discharge Pressure, psia. 

D. Compare these test values with the mean and sigma values stored in the 
sigma database. 

E. Generate the performance comparison report at each power level. 

F . Record the average values calculated for each power level in a temporary file 
for eventual update to the sigma database (to incorporated into sigma 
database upon user request). 
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4. 4. 2. 4. 3 Output 


A. Performance comparison report (see Figure 4-7). 

B . Update file for sigma database. 

4. 4. 2. 5 Green Run Analysis 

This application evaluates the test profile and engine performance against green run 
specifications and produces preliminary green run summary sheets. This preliminary green 
run summary sheet is used to determine if the tested component(s) met all green run 
requirements. 

4. 4. 2. 5.1 Input 

A. User request to perform green run analysis. 

B . User specified test number. 

C. Component(s) being evaluated. 

D. CADS and Facility data for the test. 

E. Green run specification criteria. 

4. 4. 2. 9. 2 Process 

A. Open CADS and Facility files and green run specification file. 

B . calculate accumulated time at each power level based on PC. 

C . Compare with green run specifications for minimum operating time. 

D. Calculate the point in test of: 

( 1 ) Minimum NPSP on LAX side at 104% AFL; 

(2) Maximum NPSP on LAX side at 104% RPL; 

(3) Minimum NP6P on LAX side at 109% RPL; 

(4) Maximum NPSP on LAX side at 109% RPL; 

(5) Minimum NPSP on Final side at 104% RPL; and 

(6) Minimum NP6P on Fuel side at 109% RPL. 

E. For each of these six points in the test, determine if NPSP specifications are 
met. 

F. For each of the acceptable NPSP points, calculate: 

(1) HPFT discharge temperatures; 

(2) Coolant liner delta P; 

(3) Coolant liner temperature; 

(4) Primary ox seal drain pressure; 

(5) Intermediate seal purge pressure; 

(6) Secondary seal cavity pressure; 

(7) Turbine discharge primary seal pressure; 

(8) Turbine discharge temperature; 
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FIGURE 4-7 Steady State Performance Calculations 





(9) HPOTP speed; and 

(10) HPOTP PBP Discharge pressure. 


G . Prepare specification test results for the appropriate component(s). 

4. 4. 2. 5. 3 Output 

Preliminary green run summary sheets (Figure 4-8 and 4-9). 

4.4.2. 6 Steady State Power Balance 

The steady state power balance is used to perform mass balances and calculate 
temperatures, pressures and flowrates where direct measurements are not available. From 
these operating conditions, turbine and pump efficiencies and performance ratios are 
calculated which can be used to predict the performance of the engine at alternate operating 
points and standard, rated conditions. 

The steady state power balance is a FORTRAN application which is run on the 
IBM-3084 at MSFC. This application could be ported to the Sun workstation and run 
locally or access to the IBM-3084 could be provided using the Sun as a terminal. 

4. 4. 2. 6.1 Input 

A. CADS and Facility data which has been reduced to one second average 
files. 

B . JCL to initiate program execution. 

4.4.2. 6.2 Process 

Refer to the SSME Model Documentation assembled by the Martin Marietta Model 

Group. 

4.4.2. 6. 3 Output 

A. Predicted C2 and Kf constants and rated performance of the engine at 
standard conditions (see Figure 4-10). 


4 . 5 EXPERT AIDED DIAGNOSTICS 

4.5.1 Applications List 

4.5. 1 . 1 Features Identification 

This application examines transient parameter readings to determine if specific 
features exist in the data. Features include level exceedances, step shifts, oscillations, 
decays, etc., which define potentially anomalous engine behavior. Certainty values will be 
estimated for each potential anomaly identified. 
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FIGURE 4-8 Green Run Evaluation Report for HPFTP 
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FIGURE 4-9 Green Run Evaluation Report for HPOTP 




HPOTP U/H 2TC i >'R2 ACCEPTANCE TEST RESULTS 
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FIGURE 4-9 Green Run Evaluation Report for HPOTP (Cont’d) 
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FIGURE 4-10 Steady State Performance Model Report 



4.5. 1 .2 Featurcs-to- Anomalies Generator 

This application is a user-friendly input program to allow analysts to capture the 
reasoning used to isolate specific anomalies from SSME test data. This application will be 
written using the NEXPERT Object shell. Steps include specification of critical features in 
certain data channels, associated history or configuration information, and methods for 
differentiating competing diagnoses. 

4. 5. 1.3 Expert Aided Diagnosis 

This application will assist the data analyst in sequentially examining test results 
presented using predefined plot formats. The application will be written using the 
NEXPERT Object shell. The application will accept the expert user's judgements 
concerning the existence and severity of anomalous data features and uses its inference 
mechanism to suggest failure mechanisms. 

4 . 5 . 1 . 4 Advanced Diagnostics 

Other approaches to expert aided diagnostics will he hosted by the system. 
Modules to support other programs such as "deep" reasoning about physical causality can 
be integrated directly into the workstation structure. 

4.5.2 Expert Aided Diagnostics HIPO Analysis 

4 . 5 . 2 . 1 Feature Generator 

4. 5. 2. 1.1 Input 

A. CAD and facility sensor channel data from the current test or flight. 

B. Feature database entry for sensor anomalies including the following 
elements (see Figure 4-1 1 for typical entry screen layout): 

(1) Sensor channel identifier, 

(2) Operating mode; 

(3) Feature descriptions; and 

(4) Threshold or reference values. 

4. 5. 2. 1.2 Process 

This application (see Figure 4-12) will automatically analyze test data channels to 
detect anomalous features: 

a. Open feature descriptor table defining data channels and test phases 
for examination; 

b. For each test phase (start, mainstage, and cutoff), access data for 
channels defined in feature table; 

c. For each data channel data set and feature type, (e.g. threshold 
exceedance, 2-sigma bounds checks or oscillation) call automatic 
analysis module to perform feature detection; 
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NAME: 


MCC_LN_CAV_PR 


PARAMETERS: MCC LN CAV PR 1 (1951) 

MCC LN CAV PR 2 (1952) 
MCC LN CAV PR 3 (1953) 


EEATURI 

L EhASL 

OT 

START 

UT 

START 

DIV 

START 

Oli 

ALL 


M 

UNDERSHOOT OVER 2o THRESHOLD 
BELOW 2a BAND 
SENSOR A/B/C DIVERGENCE 
LEVEL ABOVE MAXIMUM 



ABOVE 

BELOW 

DIVERGE 

ABOVE 



2a 

2a 

0.5 PSI 
0.5 PSI 



FIGURE 4-1 1 Typical Entry Screen Layout for Feature Description Table 
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Special 


/ Diagnostic \ 


Feature 

I Applications 1 

► 

List with 

\(see Section J 


Confidences 


4 . 4 ) 


Test Anomaly Index 
( see Figure4-13) 



FIGURE 4-12 The Feature Generator Detects Pre-Defined 

Characteristics in Test Data and Makes 
Entries in Feature List 
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\ 


TEST ANOMALIES INDEX 


REF 

TEST 

DATE 

PJHASE 

EA£AHETER 

feature 

RUL££ 

isi 

A2-492 

2/13/90 

START 

MCC LN CAV PR 1 

UNDERSHOOT ABOVE 2o THRESHOLD 

VES 

S2 

A2-492 

2/13/90 

START 

MCC LN CAV PR 3 

UNDERSHOOT ABOVE THRESHOLD 

YES 

Ml 

A2-492 

2/13/90 

MAINST AGE 

HPOT DS TMP 

CHANNEL A/B DIVERGENCE 

NO 

n i 

A2-492 

2/13/90 

MAINST AGE 

HPFP IN TEMP 

OVERSHOOT ABOVE THRESHOLD 

YES 

M 1 

A2-492 

2/13/90 

MAINST AGE 

PBP DS TMP 

INCREASING DURING SS OPS 

YES 


V 



FIGURE 4-13 Test Anomalies Index Presents Anomaly Features Detected 
in the Test Data and Acts as a Menu Index for Subsequent 
Data Analysis (Typical Format) 


75 


d. Analysis modules will return indication of the existence of features 
and a confidence level (e.g. measures relating to amount of 
exceedance, time over limit, and other severity indicators); and 

e. For features detected, enter feature symbol (created from feature 
name, parameter, and feature descriptor e.g. 
MCC_LN_CAV_PR_l_OT) and confidence into feature list for test 
and segment. For features defined with "negative reporting", enter 
feature name with confidence level of feature not existing. 

Features detected in the data will be combined in the Feature List with other 
diagnostic facts derived in the special diagnostic applications (see Section 4.4). The 
Feature List acts as a blackboard for expert aided diagnosis and advanced diagnostic 
applications. This blackboard file is maintained as part of the NEXPERT Object file 
system and exists outside of the integrated database. The blackboard file is the interface 
between the information in the integrated database and the diagnostic processes 
implemented in the NEXPET Object shell. 

4. 5. 2. 1.3 Output 

A. Diagnostic facts derived from the features and written to the blackboard file 
for each match or partial match of an anomalous feature in a test data 
channel. 

B . Confidence level in each fact based on the number and degree of feature 
matches between data and reference descriptors. 

4. 5. 2. 2 Features- to- Anomalies Generator 

This application will generate/update the rulebase of the expen aided diagnostics 
maintained by NEXPERT Object using tools which are part of the shell. The rules describe 
the relationships between observed data (i.e. test data, inspection reports, prior test, 
component history, and component age) and observed hardware failures. The program 
will capture the experience of the data analyst who discovers and diagnoses a new type of 
failure or it will update the reasoning path based upon experience with a recognized failure 
event. The program will be the vehicle for knowledge maintenance and will permit the 
users of the system to develop and enhance the diagnostic effectiveness of expert aided 
diagnosis through use of the workstation for data analysis: 

4. 5. 2. 2.1 Input 

A. Current knowledge (i.e. captured rules) relating the occurrence of 
anomalous data features to associated hardware or test failures. 

B . Expen experience and judgement of the data analyst user. 

4. 5. 2. 2. 2 Process 

A . Open knowledge base (maintained in NEXPERT Object). 

B . Select existing or new rule set ("knowledge island") used to process a given 
anomalous feature. 

C. Obtain decision network diagram of rule set to assist in visualization of rule 
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relationships (using NEXPERT Object feature). 

D. Update rule base structure relating observed data anomalies with causative 
hardware failures based upon new knowledge about the meaning of 
observed features. 

E. Define new data features or facts if required. 

F. For each rule, define user prompt for fact and a pre-defined plot or report 
format to be produced when the data display function is selected (at each 
step, a hot key will permit the user to have access to the test data beginning 
with a pre-defined plot format for the particular node (see Figure 4-14). 

G . On completion of user changes, update the knowledge base file (maintained 
by NEXPERT Object). 

4. 5. 2. 2. 3 Output 

An updated knowledge base (rule base) describing the relationships between 
observed anomalies, historical data, maintenance and inspection reports time/life 
considerations and hardware failures. 

4.5.2. 3 Expert Aided Diagnostics 

The expert aided diagnosis application (resident in the NEXPERT Object shell) uses 
the knowledge base and features discovered in the test data to control investigation of 
anomalies and inference concerning the cause (if any) of the problem. 

This program uses a "flat" knowledge representation which is based upon heuristic 
rules rather than reasoning on the physical phenomena causing the feature. At any point in 
the analysis of events, a list of candidate faults and confidence levels for the test can be 
displayed to the user. These faults can be influenced by analysis of any feature in the 
current test. The system will be capable of diagnosing multiple, dependent faults. 

4. 5. 2. 3.1 Input 

A. The knowledge base (rule base) describing the relationships between 
observed anomalies, historical data, maintenance and inspection reports 
time/life considerations and hardware failures. 

B . Diagnostic facts for each match or partial match of an anomalous feature in a 
test data channel or other facts concerning inspection reports, configuration 
and history. 

C. Confidence levels in the facts. 

4. 5. 2. 3. 2 Process 

A. Open Knowledge base files and feature (fact) files maintained by 
NEXPERT Object shell. 

B. Select anomaly or continue with diagnosis of anomaly if previously 
initiated. 
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FIGURE 4-14 


2 3 4 5 6 

TIME FROM START - SEC 


Pre-Defined Plot Format Is Available During Diagnosis to 
Show Basis of Feature Detection 
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C. Perform inference step (back/forward chain). If in "Auto" mode, continue 
until no more facts can be inferred. If in "Step” mode, halt before firing 
next rule and allow user options (as follows). 

D. On user selection, retrieve pre-defined report for rule. This can be a plot of 
test data, retrieval on other tables in integrated database or other report 
containing data related to the rule clauses (for example, see Figure 4-15). 

E. On user selection, allow user access to the CAE environment with default 
selections set to this test, phase, and anomaly. 

F. On user selection, suspend diagnosis process and store parameters required 
to restart process at suspended point. Exit to main menu. 

G. On user selection, obtain background information using hypertext help 
system with entry defined by specific rule being examined and dynamic 
hypertext indices set up for this test, phase, anomaly, etc. to define context 
of help. This system can contain dynamic graphics provided by the user 
interface (DataViews or SL). 

H. On user selection, alter state of one or more facts and/or confidences 
concerning features or intermediate conclusions. 

I. On user selection, allow a completed diagnosis to be stored in anomalies 
database (see Figure 4-16) which contains a history of diagnostic results 
including follow-up narratives, related inspection reports, etc.. 

J . On user selection, obtain a window with transaction log tracing the 
inference process as it has progressed to this point. 

K . On user selection, obtain a graphical representation of the inference network 
showing actual status of inference to this point. 

L. Proceed to next inference step. 

4. 5. 2. 3. 3 Output 

A. Diagnosis(es) of hardware or test failure or indication of a "false alarm" 
based upon reasoning controlled by the rules in the knowledge base. 

B . Explanation of reasoning path which lead to the conclusion(s). 

C. Other supporting data used to clear the fault or make recommendations 
concerning its importance and disposition. 

4 . 5 . 2 . 4 Advanced Diagnostics (External Applications) 

4. 5. 2. 4.1 Input 

A. Diagnostic facts for each match or partial match of an anomalous feature in a 
test data channel or other facts concerning inspection repons, configuration 
and history. 
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FIGURE 4-15 Expert Aided Diagnostics Provides a Rule 

Controlled Analysis of Test Data and Related 
Information 
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HISTORY DF SIMILAR ANOMALIES 

PARAMETER: MCC LN CAV PR 

ANOMALY: UNDERSHOOT ABOVE 2o THRESHOLD 


£££ 

TEST 

DATE 

£H ASE 

PIABNQS'IS 

Si 

A 1 -242 

1/12/88 

START 

FACILITY PURGE REQUIRED 

S2 

A2-296 

2/20/89 

START 

FACILITY PURGE REQUIRED 

S3 

A 1-347 

4/17/89 

START 

MCC LN CAV SENSOR FAULT 

S4 

A2-310 

5/30/89 

START 

UNKNOWN 

S5 

A2-395 

10/10/89 

START 

FACILITY PURGE REQUIRED 

S6 

A2-400 

1 1/1/89 

START 

FACILITY PURGE REQUIRED 


FIGURE 4-16 


Completed Diagnoses Are Incorporated into Integrated 
Database 
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B. 


Confidence levels in the facts. 


C . Other files dependent upon the external application. 

4. 5. 2. 4. 2 Process 

The workstation allows integration of externally generated applications (using the 
NEXPERT Object shell) to perform additional, focused diagnostics using information 
available from the integrated databases and interfacing with the fact (blackboard) files. For 
example, a deep reasoning inference model could be used to detect and isolate problems in 
the HPOTP using the internal thermodynamic relationships of the hardware. Applications 
of this type could use the expert system/CAE environment established by the workstation to 
obtain data and additional, related information. The interface between applications could 
then be implemented in a seamless manner with little impact on the user interface. 

4. 5. 2. 4. 3 Output 

A. Diagnosis(es) of hardware or test failure or indication of a "false alarm” 
based upon reasoning controlled by the rules in the knowledge base; 

B. Explanation of physical reasoning used to derive failure diagnosis using 
"deep" inference methods; and 

C. Other supporting data used to clear the fault or make recommendations 
concerning its importance and disposition. 


4.6 SYSTEM ADMINISTRATION 
4.6.1 Database Administration 

Database administration will be performed using file maintenance programs 
included in Ingres. Functions will include data dictionary modification, data table edits, 
and table loading. Additionally, pre-defined plot formats will be maintained by the 
database administrator so that standard plot sets can be produced by each workstation for 
each test. Local definition of pre-defined plot formats will be the responsibility of 
individual analysts. 


4.6.2 Database Backtip/Recoverv 

Data backup and recovery will utilize programs incorporated in the SUN and VAX 
processor platform workstations. File server backups will protect data from short term 
loss. Long term file backups will be based upon PE4 mass storage. Workstation data 
backups and recovery will be the responsibility of local analysts using existing workstation 
utilities. 

4.6.3 System Installation/Reconfiguration 

Software installation, reinstallation and reconfiguration will be controlled by this 
program. In addition to customizing the workstation programs to the analysis functions of 
the specific workstation, the program will install Ethernet vLAN programs necessary for 
system operation. 
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4.6.4 System Security 


System security will be provided to prevent unauthorized use of the system and to 
restrict write priveledges to the integrated databases and the diagnostic rule modules. The 
system will require a user password to enter the main diagnostic system menu. This 
password, in addition to restricting user access, will also determine the user priveledges. 
Specific user priveledge will be required to edit the contents of the integrated database and 
to modify the diagnostic rule base. The password system will be maintained by the 
database administrator. 

Simultaneous access to data by multiple users will be controlled by file and record 
locking utilities provided under Ingres. 
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